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METHOD AND SYSTEM FOR RETAIL SALE 



TECHNICAL FIELD 

The present invention relates to computer networks, and in particular to a method and 
apparatus for retail sale. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims priority from the following U.S. provisional patent applications, 
which are incorporated herein by reference: 

• serial number 60/161,392, filed 26-Oct-1999 (Attorney Docket No. PRT-004PR) 

• serial number 60/1 90,994, filed 2 1 -Mar-2000 (Attorney Docket No. PRT-004PR2) 

• serial number 60/163,150, filed 02-Nov-1999 (Attorney Docket No. PRT-006PR) 

• serial number 60/163,31 1, filed 03-Nov-1999 (Attorney Docket No. PRT-007PR) 

• serial number 60/1 64,234, filed 08-Nov-l 999 (Attorney Docket No. PRT-008PR) 

• serial number (not yet assigned), filed on 25-Sep-2000 (Attorney Docket No. PRT- 
009PR) entitled "SYSTEMS AND METHODS FOR ACCESS TO DIGITAL 
CONTENT" 

This application claims priority to co-pending application Serial Number 09/539,768 
titled "Wireless Transceiver For Communication With Tags", filed 31 -Mar-2000, Attorney 
Docket No. PRT-001, assigned to the assignee of the present invention (and incorporated herein 
by reference). This application also claims priority to copending application Serial Number 
09/615,452 filed 13-Jul-2000 (Attorney Docket No. PRT-003), which claims priority to U.S. 
Provisional Patent Application Serial Number 60/144,145, filed 16-Jul-1999 (Attorney Docket 
No. PRT-003 PR). 

BACKGROUND INFORMATION 

Modern retail point-of-sale systems allow a retail clerk to enter a customer's retail order 
into the point-of-sale system. For example, a system implemented at a coffee shop might allow a 
customer's order of "a large coffee with cream and sugar" to be entered into the point-of-sale 
system by a clerk. The point-of-sale system may display the pending order on a screen or print it 



onto a paper, so that the retail clerk, another worker or automated machinery can fulfill the order. 
Point-of-sale systems also assist the retail clerk in receiving payment by the customer to the 
retail clerk, by calculating a total for the order, and possibly by performing steps necessary to 
charge a credit card that is presented to the clerk, or by opening a cash drawer to allow the clerk 
to make change. Some point-of-sale systems allow for tallying of "bonus points" or other 
information based on a loyalty card presented to the clerk by the customer. 

SUMMARY OF THE INVENTION 

A method and system for retail sale allow a customer to efficiently order and pay for a 
pre-selected retail order. The customer uses a token, such as a magnetic stripe card or radio 
frequency identification (RFID) token to identify herself to the retail location system. The retail 
system can identify the customer, and obtain information about the customer from a local or 
remote database. The information obtained can include order information, as well as payment 
and other information. In a preferred embodiment, the invention facilitates ordering and 
payment of a customer's daily routine. In another embodiment, the invention facilitates ordering 
and payment of a pre-selected order that was made over the Internet or at an automated ordering 
station. 

In general, in one aspect, the invention relates to a computer-based method for selling an 
item to a customer at a retail location. An identifier associated with a token presented by a 
customer is received at the retail location. Customer data is accessed based on the identifier. A 
product order selected by the customer is identified. The identified customer order is prepared 
for the customer at the retail location. A preferred payment method for the customer is 
identified, and payment by the customer executed for the selected order by the preferred payment 
method. The customer is provided with the selected order at the retail location. 

In one embodiment, the token is an RFID tag. The step of receiving the identifier 
includes wirelessly reading the RFID tag. In one such embodiment, the method is performed in 
response to the single user action of presenting the RFID tag to an RFID reader located at the 
retail location. In another embodiment, the token is a magnetic stripe card, and the step of 
receiving the identifier includes presenting the magnetic stripe card to a customer-accessible 
magnetic stripe card reader located in the retail location. 
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In one embodiment, the method also includes the customer selecting an order. The 
method includes facilitating customer selection of a product order and associating the customer 
selected product order with the customer. Customer selection can be facilitated over a public 
computer network, such as the Internet. Customer selection can be facilitated at a terminal or 
5 kiosk located in the retail location. 

Customer data can be accessed from a database. Such a database may be available from 
a server accessible over a public computer network such as the Internet, or may be available over 
a local area network. The database may be operated by the retail location or by a third party. 
In one embodiment, payment is executed by providing payment information to a POS 
1 0 device for execution. In another embodiment, payment is executed by processing payment and 
providing an execution code indicating complete payment to a POS device. In yet another 
embodiment, a token (or the owner of a token) is associated with a counter having a count value, 
and payment is executed by decrementing the count value. 
CH In general, in another aspect, the invention relates to a system for selling an item at a 

g|5 retail location. The system includes a token reader for receiving at the retail store an identifier 

associated with a token presented by a customer. The system also includes a dispatch module for 
yj accessing customer data based on the identifier. The dispatch module can also identify in the 
j\ customer data a selected customer order and a preferred payment method. The system also 
P includes a display for displaying the selected customer order at the retail location to a sales clerk. 
ijiO The system also includes a POS device for executing payment by the customer for the selected 
zf order by the preferred payment method. In one embodiment, the system includes one or more 
database servers communicating with the dispatch module for providing customer data in 
response to requests. 

The foregoing and other objects, aspects, features, and advantages of the invention will 
25 become more apparent from the following description and from the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the drawings, like reference characters generally refer to the same parts throughout the 
different views. Also, the drawings are not necessarily to scale, emphasis instead generally 
30 being placed upon illustrating the principles of the invention. 



FIG. 1 schematically illustrates an embodiment of a retail sale system according to an 
embodiment of the invention. 

FIG. 2 is a flowchart of a method for retail sale according to an embodiment of the 
invention. 

5 FIG. 3 schematically illustrates an embodiment of a POS computer configured for 

operation in accordance with the invention. 

FIG. 4 schematically illustrates a server system configured for operation in accordance 
with the invention. 

FIG. 5 is a detailed block diagram of an embodiment of a server and network database 

10 system. 

DETAILED DESCRIPTION 

D Referring to FIG. 1, in a retail location, which can be a store, storefront, counter, kiosk, 

and so on, a customer 320 presents a token 307 that contains a unique identifier to the merchant. 
In one embodiment, this token is a radio frequency identification (RFID) tag 3 07 A. In another 
embodiment, this token is a magnetic stripe card 307B. 

In the retail store, a point of sale (POS) device 301 (which is often a conventional 
computer running POS software) is connected to and accepts incoming data from a Reader 300 
equipped with mechanisms to read data from magnetic stripes, RFID tokens, or both. In one 

= §0 embodiment, the connection between the Reader 300 and the POS device 301 uses a standard 

Ul 

O interface, such as serial, parallel, universal serial bus ("USB") and so on. The POS device 301 
w can be located in a variety of locations in the store, including the check-out counter or near the 

entrance of the store. The POS devices 301 can share information over a local area network 

(LAN), such that information about a token can be gathered at one station, and be passed to 
25 another. The POS devices 301 include, but are not limited to, traditional cash registers, 

computer-based cash registers, point of sale devices, in-store kiosks, touch-screen ordering 

systems, and so on. 

To read RFID tags, Reader 3 00 A emits a signal. If any of a series of tokens such as 
token 3 07 A, each comprising an embedded RFID tag (not shown) is within range of the signal, it 
30 will respond by providing its identifier to reader 300 A. In some implementations, the identifier 
is a 32 bit serial number assigned at time of manufacture and unique to that tag. Although the 
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term "RFID" is an abbreviation of radio-frequency identification, it has attained a more generic 
connotation in the art. Accordingly, as used herein, the term "RFID" broadly connotes any 
system utilizing a wirelessly readable signature or code embedded into a minuscule package, 
typically a chip that can be incorporated within an article. The term "token" includes not only 
small items (such as easily carried cards or "poker chip" disks) intended solely as housings for 
the RFID tag, but also more commonplace articles - key chains (or key tags), product containers, 
watches, jewelry, personal effects, or even credit cards or card form factors- that incorporate the 
RFID tag. The typical RFID tag is small, low-power microchip combined with an antenna. 
Reader 3 00 A transmits the excitation signal that is received by the microchip (via the antenna), 
which uses the signal both as a source of power and as means of imparting information back to 
Reader 300A. RFID Tags are made by companies including Philips, Texas Instruments, and 
Motorola. 

To read magnetic swipes, the Reader 300 contains magnetic stripe reading electronics. 
The magnetic stripe reading electronics of the reader can be supplied by original equipment 
manufacturers such as Magtek or Semtek for integration into Reader 300. Also, the magnetic 
stripe reading functionality of other peripheral devices (not shown) connected to POS devices 
301 can be used. Other common POS devices with magnetic stripe reading capabilities are made 
by companies such as Verifone and Hypercom. The magnetic stripe swiped can be on a 
traditional credit card, loyalty card, or some other kind of card or object with a magnetic stripe. 
Often, the magnetic stripe reader 3 00 A will read one or more of the tracks of information on the 
magnetic stripe card 307B. In the case of a credit card, the magnetic stripe card 307B will have a 
magnetic stripe with up to three tracks of information. In one implementation, Reader 300A will 
read the data contained in both Track 1 and Track 2, and use some combination or permutation 
of that information as a unique identifier. To create a unique identifier, elements of the 
information on the credit card magnetic stripe can be combined together, and be put through a 
function to create a unique, identifying number for that particular credit card. In one 
implementation, this can be a unique one-way hash algorithm, such as MD5. In one 
implementation, the execution of a hash algorithm on the content read from the magnetic stripe 
takes place on reader 300. In another implementation, the information on the magnetic stripe 
card 307B is passed to software resident on POS device 301 A for processing. 



Client software resident on POS device 301 A receives information about tokens 307 
through communication with reader 300. This information can already be in the form of a 
unique identifier. If it is not, the client software can modify the token data to create a unique 
identifier. For example, a one-way hash, such as MD5, can be performed on some combination 
of data to create a unique identifier. 

The client software resident on the POS device maintains communication with the reader 
300, local databases 303, and servers 305. Communication with the servers 305 is accomplished 
through client/server communication over a computer network. The client software can also 
exchange data with the operating system software and other applications resident on the POS 
device. 

The client software resident on the POS device accesses customer data based on the 
unique identifier. The unique identifier acts as a key to reference a personal profile, a set of 
information related to the customer associated with the token 307. A personal profile is 
associated with each customer and contains information about that customer. The information in 
the profile can include identifying information such as the customer's name, address, and contact 
information. The profile can also contain information that specifies accounts with specific 
merchants, such as customer identification numbers or User ID's. In addition, the profile can 
store a consumer's preferences for payment, maintain loyalty/rewards points, and store discounts 
offers and coupons. The personal profile can be held in storage local to the POS device 301, on 
a local database 303, or on servers 305 accessible over a computer network 315 such as the 
Internet. 

In one implementation, the POS device first queries the local database 303. If the unique 
identifier specifies a record, or group of records within the local database 303, information from 
that profile is obtained for use by POS Device 301. If no record is found on local database 303, 
or if the information in local database 303 is determined to be out of date, POS Device 301 will 
initiate a similar lookup for a profile corresponding to the unique identifier on servers 305. 

The information returned to POS Device 301 can be some portion or the entire contents 
of the profile associated with the unique identifier. In another implementation, servers 305 
perform heuristics on the request by POS Device 301 to determine the appropriate information to 
return. Such heuristics could include identification of an appropriate subset of the profile. This 
could be based on identification information provided by the POS Device 301 . For example, at a 




coffee shop the POS Device 301 might only require a coffee order and preferred payment 
method, and not any other information included in the profile. 



Information held in the databases that is returned to the POS Device can include 
information such as a customer identity, a pre-specified order, a payment method (such as a 
preferred credit card number), a customer loyalty number, a transaction authorization, and so on. 
For example, in a coffee shop, the information received by the POS Device in response to the 
database lookup could specify the type of coffee that is the customer's regular order, for example 
a decaffeinated latte. The information could also specify a credit card number to charge for the 
purchase, and an indication that credit card is the preferred method of payment. 

The POS Device can display the order to the customer on, for example, a display screen, 
while the staff at the retail store fulfill the order. If a preferred payment method is specified, the 
POS Device 301 can execute payment. For example, if the customer's preferred payment 
method is a debit card, POS Device 301 can execute the debit transaction. 

Once the order is prepared, the order is provided to the customer. The database 
information in the profile can include the customer's name, so that the customer can be called 
and thanked for his order, for example: "here is your order Mr. Smith, thank-you very much." 

Using the system described, the retail transaction process includes other opportunities for 
added value to the consumer. This can include, but is not limited to, loyalty programs, rewards 
benefits, and affiliate (or referral) information. A user's loyalty and reward points can 
automatically be accessed and updated through the system. 

The system can also facilitate the access to and redemption of discounts, or coupons. 
Personalized promotions or product discounts can be stored as part of a profile. For example, in 
one implementation, when a customer visits a product website, merchant coupons are loaded into 
the customer's profile in a database, accessible through the system's Information Servers. Stored 
coupons are then automatically redeemed when the payment system is used. 

Referring to FIG. 2, a method for selling an item at a retail location includes the step of 
receiving at the retail location an identifier associated with a token presented by the customer 
(Step 500). In one embodiment, the identifier is associated with an RFID token. RFID tokens 
include not only small items, such as easily-carried cards or "poker chip" disks, intended solely 
as housings for the RFID tag, but also more commonplace articles that incorporate the RFID tag, 



such as key chains (or key fobs and tags), product containers, watches, jewelry, personal effects, 
and even credit cards and card form factors. 

In another embodiment, the identifier is associated with a magnetic stripe (magstripe) 
card. The magnetic stripe swiped can be on a traditional credit card, debit card, bank card, 
loyalty card, rewards card, or some other kind of card or object with a magnetic stripe. 

The user presents the token to a reader that is located within the retail location. There 
may be several such readers in a retail location. For example, there can be a reader located 
proximate to the store entrance, and a reader located proximate to the retail point of sale. A 
reader could be located proximate to product display shelves. A reader could be located 
proximate to a customer table in a restaurant or coffee shop. 

The method includes accessing customer data based on the identifier (Step 501). The 
customer data can be contained within a database local to the point of sale device, or local to the 
retail location accessible through a local area network (LAN). The customer data can also be 
held in databases accessible across a public network, such as the Internet. The customer data can 
also be accessible across a private networked system including databases accessible over 
corporate intranets, a proprietary corporate network, a wide-area network, or the internet. The 
customer data can be held in databases operated by the retail merchant, or in databases operated 
by another entity. In the case where the database is operated by another entity, the customer data 
can be passed back directly to the point of sale device, or the data can be staged to a retail 
merchant server that communicates with the point of sale device. 

The method also includes the step of identifying in the customer data a product order selected 
by the customer (Step 502). For example, in a coffee shop, the information received by the POS 
Device in response to the database lookup could specify the type of coffee the customer wants 
(e.g. a decaffeinated latte). In this case, a customer can specify a particular kind of item to be 
ordered every time the system is used. The setting of this preference can occur at the retail store 
by retail personnel, or through direct customer interaction with a system allowing the setting of 
preferences, such as a kiosk. For instance, the customer can use a kiosk in the retail setting that 
allows the customer to set a preference by selecting an item on a menu with a touchscreen. The 
setting of preferences can also occur over the internet. In one example, a customer sets order 
preferences on the website of a retail merchant through a system on a merchant website system 
that allows such preferences to be set. Preferences can be set to always order the same item, or 




rules can be set that allow different items to be ordered at different times, locations, and 
circumstances. For instance, a customer can specify that they want caffeinated beverages in the 
morning, but decaffeinated beverages in the afternoon. The order can also be individually pre- 
specified for each transaction. For instance, a customer can order a hamburger with french fries 
from the website of a merchant, then show up at the merchant's retail location to obtain the item 
ordered. Upon presentation of the token to the reader, the order for the hamburger with french 
fries will be processed. 

The method also includes the step of preparing the identified customer order at the retail 
location (Step 503). This action is merchant specific, in that a merchant can view the order and 
perform the necessary functions to fulfill it. For the coffee shop example, this would entail 
making the coffee product to the specification of the customer. In a newstand, this entails 
finding the customer's standing order and giving to him. In a bookshop, this could entail 
locating the customer's pre-specified book. The system can have a component that allows the 
execution of the order to more easily occur. This can include a computerized display system that 
allows personnel of the retail merchant to view pending orders. 

The method also includes identifying in the customer data a preferred payment method for 
the customer (Step 504). Again, using the coffee shop as an example, a credit card number can 
be used for payment. Here, a credit card number is delivered to the POS device to pay for the 
transaction. In this case, the credit card number, the expiration date, and the name of the 
cardholder are delivered from a database to the point of sale device for payment processing over 
a standard retail payment processing network. In another case, a bank card number, or check 
card number is delivered. In another case, a debit card number is delivered. In general, a 
number, possibly along with extra verification information, can be delivered to the POS device 
that can be used to process the transaction. A customer will often only have one payment 
method specified for use with the system. In cases where there are more than one payment 
methods registered in the system by a single customer, the "preferred" payment mechanism is 
used. The customer is asked, upon entering multiple payment methods, to specify a preferred 
method. In another example, the customer is given the choice at the POS to choose a preferred 
payment mechanism for the present transaction from several options. 

The method also includes executing payment by the customer for the pre-selected order by 
the preferred payment method (Step 505). Still continuing the coffee shop example, the credit 




card number identified above is sent over a standard retail payment processing network for 
authorization. Settlement and clearance of the transaction occur according to the system 
employed by the retail merchant. Payment can be executed in real-time through existing 
payment processing networks, such as credit card and debit networks. In another example, 
payment is executed in a batch transaction at a time interval determined by the retail merchant 
(for instance, once every two hours). 

In another embodiment, payment is executed through a third-party. For example, as noted 
above, a third-party can operate the databases that store the customer data. Such a third party 
could provide a credit card number for completion of the transaction. In another example, a 
third-party could execute payment for the transaction directly with a payment processor, and 
return an authorization code to the POS upon completion of the process. In another example, 
payment can be executed through an alternative network to the established credit and debit 
networks. For example, in the coffee shop, payment for the merchant can be received through a 
stored-value network, such as PayPal. In this example, the customer data includes that 
customer's PayPal account number. The merchant is then able to obtain the correct amount of 
money from the customer's PayPal account. 

The method may include the customer providing a password or personal identification 
number (PIN) as part of payment execution, or earlier. Such password or PIN can be used to 
authenticate the customer to the system. The password or PIN can be an authentication 
challenge associated with an existing payment network, for example, a PIN associated with a 
debit card network. As another method of authentication, the customer's photograph can be 
displayed on a screen for viewing by the retail location personnel. 

In one embodiment, the token can be set to be used a certain number of times. Each time 
the object is used, the system registers its use, and renders it inactive after that number of uses. 
This function can act like a debit card. In this example, a person can pre-pay for 10 purchases of 
a specific item from the retail store. Once the customer uses the token 10 times, to buy 10 items, 
the token will be rendered inactive. In this embodiment, executing payment includes obtaining a 
count value associated with the token, and if the count value is greater than zero, decrementing 
the count value. 

The method also includes providing the customer with the selected order at the retail point of 
sale (Step 506). This action is merchant specific, in that a merchant can fulfill the order in an 




appropriate manner. For the coffee shop example, this would be providing the coffee product to 
the customer. The system can have a component that allows the execution of the order delivery 
to more easily occur. This can include a computerized display system that allows personnel of 
the retail merchant to view names of the customers, view pictures of the order recipients, or 
obtain information about where the customer is located in the retail location (e.g. at which table 
they are seated). 

The steps associated with this method can be performed in a different order than just 
described. For example, in one embodiment, the steps of identifying the order and identifying 
the payment information occur concurrently as a customer's personal profile is obtained. In 
another embodiment, the order is provided to the customer even before payment is executed. 

In one embodiment, the method steps are performed in response to a single user action, 
where the single user action is the presentation of the token to the reader. In one embodiment the 
single user action is the waving of an RFID token proximate to a RFID reader, in another 
embodiment the single user action is the moving of a magnetic stripe card through a magnetic 
card reader. In either case, the user is, through this single action, able to initiate the ordering and 
payment of the selected goods in a retail store. This method, simply initiated with a single 
action, allows a user quick access to her daily routine, for example. 

Referring to FIG. 3, in one embodiment, a POS Device 301 is a general purpose 
computer running POS software application 80, as well as reader interface software 84 for 
communicating with the reader 15 and local and remote databases. The POS Device includes a 
CPU 56, RAM and ROM memory 54, a screen display 75, mass storage 56 such as a hard disk, a 
keyboard 70 and a position sensing device 72 such as a mouse. The POS Device 301 is also 
connected to a reader 15, such as the RFID reader or magnetic stripe reader described above. 

The reader interface 84 determines whether signals received from reader 1 5 in fact 
indicate the presence of a token 20. The reader interface 84 checks data generated by the reader 
1 5 for proper format and parity, thus eliminating spurious signals due to noise. The dispatch 
module 82 responds to the presence of signals received from the reader interface 84. In one 
embodiment, the signals received from the reader interface 84 include a token identifier. In 
another embodiment, the signals received from the reader interface 84 include the type of token 
20 associated with the identifier, and the software version of the reader 15. Other information 



can be stored on the token besides the identifier, and in another embodiment, that information is 
communicated by the reader interface 84 to the dispatch module 82. 

In the embodiment of FIG. 3, the dispatch module 82 obtains personal profile information 
in response to the identifier from another computer 99 that is connected to the network 62. In 
one embodiment, the dispatch module 82 sends a request to the computer 99 that can include the 
identifier and other information. Such other information can include another unique identifier 
associated with the reader. The reader identifier, if included in the request, can be used to 
identify the source of the request (for authentication) or to limit or filter the personal profile 
information that is to be returned. The computer 99 responds with some or all of the profile 
information, and possibly other information. Based on the information communicated from the 
computer 99 to the dispatch module 82, the dispatch module 82 communicates with the POS 
application 80. 

The embodiment of FIG. 3 has the advantage of not requiring the database 85 on 
the POS computer to be kept up to date as new tokens 20 (with new identifiers) are introduced, 
because the identifier/access criterion matching is performed by the computer 99. In one 
embodiment, an on-board database 85 is used to store identifiers, access criteria and other related 
information. In one embodiment, the database 85 acts as a cache to store temporarily the 
information and associated access criteria. In another embodiment, the database 85 is also stored 
on mass storage 52 so that the database 85 accumulates and stores each identifier/access criteria 
once it is determined. 

Referring to FIG. 4, a Point Of Sale Device (POS Device) 600 is used to perform a retail 
transaction. In one embodiment, the POS Device 600 has an architecture similar to a general 
purpose computer, and may even.be a general purpose computer. The POS Device 600 includes 
an operating system and various network applications 632 that allow the computer to function as 
a retail transaction device. 

The POS Device 600 includes client software 605 that coordinates token-related events. 
It processes token-related events that occur at each POS Device 600, formulates queries to the 
appropriate information servers 650 to obtain customer information to complete transactions, and 
controls the user interface to the system for both the customer and the retail personnel. The 
client software 605 has been implemented with three distinct functional layers, a user interface 
layer 608, a worker pipeline layer 610, and a device manager layer 620. Each of the layers 




contain various software components that coordinate operations on those three functional areas. 
The user interface layer 608 formats and presents information to the customer and retail 
personnel. The user interface layer 608 also controls new user registration and profile 
management workflow. The worker pipeline layer 610 performs operations on token data and 
customer data on the POS Device. 



The worker pipeline layer 610 is structured as a queue of software components, also 
referred to as "workers," that process software events in a sequential manner. The pipeline 
controls caching, token identification, personal data manipulation, and error handling. 

The token worker 614 is a module for handling token-related events, such as tag 
presentation or card swipe and the token worker 614 processes tag and swipe-related data. The 
token worker 614 performs operations on the information that results from tag and swipe events 
that make the data from those events meaningful to other components of the software. 

The profile worker 616 is a module that manipulates customer profile data for use by 
other components of the software. The error worker 61 8 is a module that handles error states in 
the client software 605, and provides notifications to the user interface layer when error states 
occur. 

The device manager layer 620 of the client software 605 is a software component that 
controls and organizes the specialized device managers, such as the data manager 622, 
application manager 624, reader manager 626. Since the managers in the device manager layer 
620 provide many useful functions for communications control, they are used for many purposes 
within the system, including communications with the reader 635, network applications 632, and 
servers 650. 

The data manager 622 is the centralized point of contact for information requests from 
other client components. By centralizing requests for information, the amount of code required 
to connect the client software 605 to one of the servers 650 is reduced. The data manager 622 
also assists with implementing encryption and fetching of data. Because the data manager 622 is 
a device manager 620, it keeps the asynchronous nature of network operations from disrupting 
client workflow. For example, errors in network operations will not disrupt the worker pipeline 
layer 610, allowing continued normal operations for areas and locations without errors. 

The application manager 624 controls and organizes communications between the 
applications on the point of sale POS Device 600, the operating system of the POS 632, and the 
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rest of the client software 605. In one embodiment, this manager is implemented as a set of 
COM interfaces for inter-application communication. 

The reader manager 626 is a device manager that controls, organizes, and accepts 
information from the one or more readers 635 (shown as one reader in the figure) connected to 
5 the POS 600. The reader 635 is the hardware interface with a RFID tag or a magnetic stripe 
card. 

Also included on POS device 600 are network applications 632. These network 
applications are software applications running on the point of sale device used for a transaction, 
or other purposes. The operating system software, which can be such standard operating systems 
10 as the SurePOS system from IBM, or the Advanced Store@Retail product suite from NCR, is 
also considered here to be a network application, although the the client software 605 needs to be 
able to effectively run on the operating system 632 of the POS Device 600 to work. The client 
software 605 may communicate information to various network applications 632. For instance a 
network application 632 might be a software application to implement a loyalty program used by 
2 5 the retailer to award customer loyalty. The client software 605 can exchange information with 
the loyalty program software. 

A function of the client software 605 communicates with servers 650 over a network. 
The XML/SOAP library 630 is network software that handles the details of communicating with 
the servers. In one implementation, data passed between the client 605 and the servers 650 is 
! J|0 passed using a form of extensible markup language, or XML. 

In one embodiment, Client/Server data communication is achieved through an XML 
based protocol called the Simple Object Access Protocol, or SOAP. SOAP is a lightweight 
protocol for exchange of information in a decentralized, distributed environment. SOAP 
messages consist of three parts: an envelope that defines a framework for describing what is in a 
25 message and how to process it, a set of encoding rules for expressing instances of application- 
defined datatypes, and a convention for representing remote procedure calls and responses. 
SOAP messages can be, and in this case are, carried in hypertext transfer protocol (HTTP) 
messages. 

The client 605 communicates with information servers 650 to acquire data on customers 
30 and take necessary actions. The information servers 650 are a collection of servers and databases 
that take input from the client software 605 and return the appropriate information back to the 
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POS Device 600. For instance, the client software 605 can send to the servers 650 a unique 
identifier and a reader 635 location. The servers 650 will process the information and return the 
appropriate personal profile information in response. The information servers 650 can also 
communicate with third party servers such as payment processors 640, partner servers 642, and 
merchant servers 644. The information servers are comprised of a series of servers with various 
functions. 

An error server 652 receives error state notifications from client software 605. Most error 
state notifications are reports of network faults. The error server is separate from the other 
servers to prevent a load spike from an error at a malfunctioning destination from "flooding" the 
rest of the system with requests. A context server 654 coordinates responses of the system based 
on locations of the request. The location of the request can be determined, for example, by the 
internet protocol address of a requesting system, or by a reader identifier associated with the 
request. The information sent back to the client software 605 can vary based on location, time, 
sequence of events, and so on, in other words, based on the context of the request. A profile 
server 656 coordinates the network storage and retrieval for profile data. Since this server's 
responses change based on client interaction, this is a dynamic server. Therefore, the profile 
server 656 is implemented with a full database back-end, such as an Oracle, SQL Server 2000, or 
Postgresql database. 

A registration server 658 provides the mappings between tokens and users, and ensures 
all system identifiers are unique. This server also plays a role in pre-registration of tokens for use 
in the system. A transaction server 660 communicates with payment processors and specializes 
in the handling of sensitive financial data. 

The servers 652, 654, 656, 658, 660 draw information from databases, also shown as part 
of servers 650. Reader database 662 contains information about the population of readers 635. 
Profile database 664 contains personal information on each user of the system. Token database 
668 contains information about the population of tokens deployed. This includes information on 
both RFID tags and magnetic stripe cards. 

Through the same XML/SOAP protocol used to talk to the client software 605, the 
information servers 650 can share information with payment processors 640, partner servers 642, 
and merchant servers 644. Payment processors 640 are third party processors of payment 
transactions. These are, for example, merchant banks that can authorize, settle, and clear credit 




card, debit, and other financial transactions. Payment processors 640 can also include other 
payment transaction processing networks outside of the credit and debit systems, such as PayPal 
from X.com. Partner servers 642 are servers in partner organizations that provide data for 
transaction processing, loyalty/rewards tracking, coupon or discount giving, or report 



5 submission. Merchant servers 644 are information servers operated by the retail merchant. 
These can be used in running both retail operations and website operations. The system is 
designed such that the information servers 650 can share information directly with merchant 
servers 644 to streamline inventory, reporting, user registration, and so on. 

The networked architecture of this system allows the same payment object to perform 
10 different functions depending on location and context. Context-dependant action is primarily 
enabled by identifying the reader location. For example, the same identifying token that 
identifies a person to one retail store can be used at different retail locations with different 
O merchants or companies. For instance, in one implementation, the same token used in the coffee 
m shop example can be used in an airport check-in system to pass the appropriate customer 
information to the airline check-in staff, or airline check-in system. 

ff! In another example, Frequent Flyer cards (enabled with an unique identifier such as a 

Ql 

y magnetic stripe or RFID tag) used with the system can allow instant account access and online 

* ticket ordering at home and immediate check-in at the airport. The system can determine 

0 whether the person is using the system from their home or from the airport based on information 
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y20 passed during the transaction. In each context-dependent case, the system architecture remains 

Q similar, with slight variations to account for the workflow of a device. For instance, a retail store 

p 

might keep a mirror copy of elements of the profile database that are critical for quick- 
turnaround performance. A coffee shop might keep preference information about loyal 
customers that live in the area on a database local to the shop that can be updated on a regular 

25 schedule from the online profile database. 

In one implementation, a version of the Magstripe/RFID Reader referenced throughout 
this document is connected to a personal computer, possibly at a customer's home or place of 
work. The system also includes software running on a personal computer (referred to as the 
"client," similar to the client software on the POS device) that receives information from the 

30 reader device, performs functions on the information, and has the ability to communicate with a 
networked server and database, possibly over the Internet. 



This system can provide different functionality for customers with identifying tokens 
outside of the retail environment. For example, in one implementation, the swipe of a magnetic 
stripe credit card by a consumer through the Reader while on the retail merchant's website 
causes an online order form to be filled out, and initiates online payment using information from 
that credit card and associated with that person. 

Following the same mechanisms used in the retail store, the magnetic stripe swipe acts as 
the unique key to identifying a person. It serves to unlock payment, preference, and other profile 
resources from a data source, either locally held or on a network. 

Referring to FIG. 5, in one embodiment, a server and networked database system 800 act 
as the backbone to a tag-enabled system, such as the system described above. The server maps 
identifying information from each tagged object to targeted response information. The result can 
be, as described above, personal profile information used for the initiation of a retail transaction. 

In one embodiment, the networked database system 800 includes relational databases 
804A, 804B, 804C (generally 804) that store information about the deployed tags, readers, the 
user community and the merchant community. In one implementation, common open products 
are used for the primary databases 804, so the system uses standardized SQL as the query 
language. The system thus leverages state-of-the-art database techniques independent of 
particular hardware or software vendors, to easily integrate advances in database technology, and 
to enjoy enhanced interoperability with partner organizations. 

Surrounding the database core 802 in one embodiment are middleware gateways 808 
which handle requests from the outside, restricting access to only the data that is appropriate for 
the channel and site. The middleware gateways 808 also perform the protocol conversions 
necessary for interoperating with the outside devices, and runs heuristics for forming meaningful 
responses to queries. In one embodiment, the middleware gateways 808 make use of secure 
encryption technology. Specifically, SSL protocol is used to protect all network activity. 

In one embodiment, the middleware gateways 808 include home point of sale (POS) and 
home access gateway 810. Players or readers in the home 820 access the system through this 
gateway 810. The gateway 810 relays the request into the core 802, and formulates a response to 
the home system that mediates the client's next action. The data passed between the client 
running on the home machine and the home gateway 810 is not visible to the consumer and 
employs a protocol optimized for maximum efficiency and scalability. 



In one embodiment, the middleware gateways 808 include a personal administration 
portal gateway 812. The system generates personal portal-like pages on Internet-accessible, or 
system accessible, terminals 822 from this knowledge base. Through the personal portal 812, the 
system provides to a user administrative control over the information that is on file about the user 
and how it may be used. 

In one embodiment, the middleware gateways 808 include a retail integration gateway 
814 for integration into relevant retail systems of customers. Retail systems 824 such as point of 
sale terminals, kiosks, and other connection points access the databases through this gateway 
814. In another embodiment, the middleware gateways 808 include a payment processing 
gateway 816, which interacts with the retail integration gateway 814, and provides an interface to 
third-party transaction clearing houses through this gateway 816. The payment processing 
gateway 816 can also interact with the Home POS and Access gateway 810. 

In one embodiment, the middleware gateways 808 include a distributed caching gateway 
818. For some applications and installations, it is necessary to cache content on a computer, 
server, or other storage medium 828 close to the user. This increases reliability and ensures 
smooth operation of certain business segments. 

In one embodiment, the middleware gateways 808 include a partner administration and 
access gateway 819. Through this gateway 819, partners who distribute tokens and readers 
receive reports on their customers' usage and actions, and control the behavior of the systems 
they have deployed through their own control system 830. 

In another embodiment, the middleware gateways 808 include a gateway for integrating 
physical access control systems (not shown). RFID technology is pervasively used for building 
access control and garage access control. This gateway acts as an interface to legacy systems 
and newly deployed systems for such physical access control systems. 

Variations, modifications, and other implementations of what is described herein will 
occur to those of ordinary skill in the art without departing from the spirit and the scope of the 
invention as claimed. Accordingly, the invention is to be defined not by the preceding 
illustrative description but instead by the spirit and scope of the following claims. 



